FIPS 186-5
Google翻訳 + てきとうな修正
連邦情報処理標準規格 186-5
発行日: 2023年2月3日
発効日: 2023年2月3日（実装スケジュールを参照）
デジタル署名標準規格 (DSS) の発表
連邦情報処理標準規格 (FIPS) は、米国国立標準技術研究所 (NIST) が合衆国法典 15 編 278g-3 に基づき策定し、商務長官が合衆国法典 40 編 11331 に基づき発行します。
1. 規格名称: デジタル署名標準規格 (DSS) (FIPS 186-5)
2. 規格カテゴリ: コンピュータセキュリティ。サブカテゴリ: 暗号化。
3. 説明: この規格は、手書き署名ではなくデジタル署名を必要とするアプリケーション向けのアルゴリズムを規定しています。デジタル署名は、コンピュータ上でビット列として表現され、署名者の身元とデータの整合性を検証するための一連の規則とパラメータを用いて計算されます。デジタル署名は、保存データと送信データの両方に生成できます。
署名生成では秘密鍵を用いてデジタル署名を生成します。署名検証では、秘密鍵に対応する公開鍵を使用しますが、秘密鍵は秘密に保持する必要があります。署名者の公開鍵を用いることで、誰でも署名を検証できます。署名生成を実行できるのは、秘密鍵を保有するユーザーのみです。
署名生成プロセスでは、署名対象データの要約版を取得するためにハッシュ関数がよく使用されます。要約版のデータは、メッセージダイジェストと呼ばれることがよくあります。メッセージダイジェストは、デジタル署名アルゴリズムに入力され、デジタル署名を生成します。使用するハッシュ関数は、FIPS 180「セキュアハッシュ標準（SHS）」およびFIPS 202「SHA-3：順列ベースハッシュおよび拡張可能出力関数」に規定されています。FIPS承認のデジタル署名アルゴリズムは、適切な承認済み関数（例えば、FIPS 180またはFIPS 202に規定されているハッシュ関数など）と組み合わせて使用する必要があります。
デジタル署名は、署名されたデータと共に、意図された検証者に提供されます。検証者は、署名者の公開鍵と、署名の生成に使用されたものと同じハッシュ関数を用いて署名を検証します。保存データと送信データの両方に対して、同様の手順で署名を生成および検証することができます。
この規格はFIPS 186-4に取って代わります。将来的には、FIPS出版物またはNIST特別出版物において、追加のデジタル署名方式が規定され、承認される可能性があります。
4. 承認機関：商務長官
5. 維持機関：商務省、国立標準技術研究所、情報技術研究所、コンピュータセキュリティ部門
6. 適用範囲：本規格は、米国法典第10編第2315条または米国法典第44編第3502条(2)の適用を受けない、機微な非機密情報の保護に関して、すべての連邦政府省庁および機関に適用される。本規格は、連邦政府省庁および機関が運用する、または契約に基づきそれらのために運用される公開鍵ベースの署名システムの設計および実装に使用される。本規格は、民間および商業組織が採用および使用することができる。
7. 用途：デジタル署名アルゴリズムは、署名されたデータの完全性と署名者の身元を認証することを可能にする。署名されたメッセージの受信者は、デジタル署名を証拠として、署名が実際に署名者によって生成されたことを第三者に示すことができる。これは、署名者が後日署名を容易に否認できないため、否認防止と呼ばれます。デジタル署名アルゴリズムは、電子メール、電子送金、電子データ交換、ソフトウェア配布、データストレージ、およびデータの完全性保証とデータ出所の認証を必要とするその他のアプリケーションでの使用を目的としています。
機関は、デジタル署名鍵ペアを他の目的に使用しないよう注意する必要があります。
9. その他の承認済みセキュリティ機能：本規格に準拠するデジタル署名の実装は、連邦政府の機密情報の保護のために承認された暗号化アルゴリズム、暗号化鍵生成アルゴリズム、および鍵確立技術を採用するものとします。承認済みの暗号化アルゴリズムおよび技術には、次のいずれかが含まれます。
a. 連邦情報処理標準規格（FIPS）で規定されているもの
b. FIPSまたはNIST勧告で採用されているもの
c. FIPS 140-3の承認済みセキュリティ機能リストで規定されているもの
10. 輸出管理：特定の暗号化デバイスおよびそれらに関する技術データは、連邦輸出規制の対象となります。本規格を実装した暗号化モジュールおよびそれらに関する技術データの輸出は、これらの連邦規制に準拠し、米国商務省産業安全保障局の許可を得る必要があります。輸出規制に関する情報は、https://www.bis.doc.gov で入手できます。 11. 特許：本規格のアルゴリズムは、米国または外国の特許によって保護されている場合があります。
12. 実装スケジュール：本規格は、最終発行後直ちに発効します。FIPS 186-5への移行を容易にするため、FIPS 186-4は本規格の発行後1年間有効であり、その後FIPS 186-4は廃止されます。
13. 仕様：連邦情報処理標準（FIPS）186-5デジタル署名標準（添付）。
14. 要件：デジタル署名システムのセキュリティは、署名者の秘密鍵の機密性を維持することに依存します。したがって、署名者は秘密鍵の漏洩を防ぐ必要があります。本規格は、デジタル署名生成に関する一般的なセキュリティ要件を規定することを意図していますが、本規格への適合は特定の実装の安全性を保証するものではありません。デジタル署名機能を実装するモジュールが安全な方法で設計および構築されていることを保証するのは、実装者の責任です。
同様に、本規格に準拠した実装を含む製品の使用は、その製品が使用されるシステム全体のセキュリティを保証するものではありません。各機関または省庁の責任当局は、実装全体が許容可能なレベルのセキュリティを提供することを保証するものとします。
この種の規格は、科学技術の進歩と革新に適応できる柔軟性を備えていなければならないため、本規格は5年ごとに見直しを行い、その妥当性を評価します。
15. 免除手続き：連邦情報セキュリティマネジメント法（FISMA）は、商務長官によって義務付けられた連邦情報処理標準（FIPS）の免除を認めていません。
17. この出版物の引用方法：NISTは、NISTテクニカルシリーズ出版物識別子構文に基づき、NIST FIPS 186-5をこのFIPSの出版物識別子として割り当てています。NISTは、以下の形式で引用することを推奨しています。
米国国立標準技術研究所 (2023) デジタル署名標準 (DSS)。
18. お問い合わせおよびご意見：このFIPSに関するお問い合わせおよびご意見は、fips186-comments@nist.gov までお送りください。
連邦情報処理標準規格 186-5
デジタル署名標準 (DSS) の仕様
目次
(略)
1. はじめに
本標準は、バイナリデータ（一般にメッセージと呼ばれる）の保護、およびそれらのデジタル署名の検証と妥当性確認に使用可能なデジタル署名生成手法を定義する。3つの手法が承認されている。
(1) RSAデジタル署名アルゴリズムは、インターネット技術タスクフォースのRFC（Request for Comments）8017 1で規定されており、以前は公開鍵暗号標準（PKCS）#1 2で規定されていた。FIPS 186-5は、これらの標準のいずれかまたは両方の実装の使用を承認し、鍵ペア生成および追加要件を規定している。 (2) 楕円曲線デジタル署名アルゴリズム（ECDSA）は、本標準で規定されている。
ECDSAは、元々は米国規格（ANS）X9.62 3（廃止）で規定されていた。決定論的署名生成手順を備えたECDSAの派生である決定論的ECDSAも承認されており、IETF RFC 6979 4で規定されている。 連邦政府によるECDSA（決定論的ECDSAを含む）の使用に推奨される楕円曲線は、NIST特別刊行物（SP）800-186 5 に記載されている。 (3) エドワーズ曲線デジタル署名アルゴリズム（EdDSA）は、IETF RFC 8032 6 で規定されている。FIPS 186-5はEdDSAの使用を承認し、追加の要件を規定している。 連邦政府によるEdDSAの使用に推奨される楕円曲線は、SP 800-186 5 に記載されている。また、EdDSA署名がメッセージ自体ではなくメッセージのハッシュに基づいて生成されるEdDSAのバージョンであるHashEdDSAも含まれている。 デジタル署名アルゴリズム（DSA）は、この標準では規定されておらず、以前に生成されたデジタル署名の検証にのみ使用できる。完全な仕様は、連邦情報処理標準（FIPS）186-4 FIPS 186-4 に記載されている。 この規格には、有効なデジタル署名に必要な保証を得るための要件が含まれています。これらの保証を得るための方法は、SP 800-89「デジタル署名アプリケーションの保証を得るための推奨事項」8に記載されています。デジタル署名の生成と検証に使用される鍵長、および署名が安全であると想定される期間に関する情報は、SP 800-131A 9に記載されています。なお、この規格のアルゴリズムは、大規模量子コンピュータからの攻撃に対する耐性を提供することは想定されていません。 量子コンピュータからのセキュリティを提供するデジタル署名アルゴリズムは、今後のNIST出版物で規定される予定です。
2. 用語、頭字語、数学記号の用語集
2.1 用語と定義
2.2 頭字語
2.3 数学記号
3. 全般的な考察
デジタル署名は、書面署名の電子的な類似物であり、署名者が情報に署名したことを保証するために使用できます。さらに、デジタル署名は、署名後に情報が改ざんされたかどうか（つまり、署名されたデータの完全性）を検出するために使用できます。これらの保証は、データが伝送中に受信されたか、ストレージから取得されたかに関係なく得られます。本規格の要件を満たす適切に実装されたデジタル署名アルゴリズムは、これらのサービスを提供できます。
図1：デジタル署名プロセス$ ^5
$ ^5 EdDSAの場合、メッセージ/データは署名生成および検証プロセスに入力される前にハッシュ化されません。
デジタル署名アルゴリズムには、署名生成プロセスと署名検証プロセスが含まれます。署名者は生成プロセスを用いてデータにデジタル署名を生成します。検証者は検証プロセスを用いて署名の真正性を検証します。各署名者は公開鍵と秘密鍵を持ち、その鍵ペアの所有者となります。図1に示すように、署名生成プロセスでは秘密鍵が使用されます。鍵ペアの所有者は、秘密鍵を用いてデジタル署名を生成する権限を持つ唯一の主体です。他の主体が鍵ペアの所有者を名乗り、秘密鍵を用いて不正な署名を生成することを防ぐため、秘密鍵は秘密にしておく必要があります。承認されたデジタル署名アルゴリズムは、署名者の秘密鍵を知らない第三者が、別のメッセージに署名者として有効な署名を生成することを防ぐように設計されています。言い換えれば、署名は偽造できないように設計されています。この規格では、署名者または鍵ペアの所有者を指すために、いくつかの代替用語が使用されています。将来デジタル署名を生成することを意図する主体は、署名対象者と呼ばれることがあります。署名されたメッセージの検証前は、署名者の実際の身元について十分な保証が得られるまで、署名対象者は「主張署名者」と呼ばれます。
公開鍵は署名検証プロセスで使用されます（図1参照）。公開鍵は秘密にする必要はありませんが、その完全性は維持されなければなりません。メッセージダイジェストと公開鍵を使用すれば、誰でも正しく署名されたメッセージを検証できます。
RSA、ECDSA、HashEdDSAの署名生成プロセスと検証プロセスの両方において、メッセージ（すなわち署名されたデータ）は、承認されたハッシュ関数を用いて固定長のメッセージ表現に変換されます。元のメッセージとデジタル署名の両方が検証者に提供されます。
検証者は、署名が実際にデジタル署名を生成したと主張する主体（すなわち主張署名者）に属していることを検証するために公開鍵が使用されていることを保証する必要があります。つまり、検証者は、署名者がデジタル署名の生成と検証に使用される公開鍵/秘密鍵ペアの実際の所有者であることを保証する必要があります。この保証は、所有者のIDと公開鍵が、公開鍵基盤から発行された証明書などによって結び付けられている場合にのみ提供できます。検証者はまた、鍵ペアの所有者が公開鍵に関連付けられた秘密鍵を実際に所有していること、および公開鍵が数学的に正しい鍵であることも保証する必要があります。
これらの保証は、公開鍵を使用してデジタル署名を正しく検証できる場合、デジタル署名が有効である（つまり、鍵ペアの所有者が実際にメッセージに署名した）ことを検証者に伝えます。
デジタル署名の検証には、デジタル署名を（数学的に）検証することと、適切な保証を得ることの両方が含まれます。このような保証が必要な理由は次のとおりです。
1. 検証者が、署名者が署名検証に使用される公開鍵の鍵ペアの実際の所有者であるという保証を得られない場合には、署名偽造の問題は、身元を偽って主張する問題へと矮小化されます。例えば、数学的に整合性のある鍵ペアを所有している人は誰でも、メッセージに署名し、署名者がアメリカ合衆国大統領であると主張することができます。
2. 署名検証に使用される公開鍵が数学的に有効でない場合、署名アルゴリズムの暗号強度を確立するために用いられる議論は適用されない可能性があります。所有者は、その公開鍵で検証可能な署名を生成できる唯一の当事者ではない可能性があります。
3. 公開鍵基盤が、鍵ペアの所有者が自身の公開鍵に対応する秘密鍵を知っていることを証明したことを検証者に保証できない場合、悪意のある主体が、自身の身元（または想定される身元）を、他の当事者によって使用されている（または使用されていた）公開鍵に結び付けることが可能になる可能性があります。悪意のある主体は、他の当事者によって署名された特定のメッセージの送信元であると主張する可能性があります。また、悪意のある主体が、特定のメッセージの署名の検証を可能にすることを唯一の目的として選択された公開鍵の所有権を取得する可能性もあります。
図2：署名対象者による初期設定
技術的には、デジタル署名アルゴリズムで使用される鍵ペアは、デジタル署名以外の目的（鍵の確立など）にも使用できます。ただし、本規格で規定されているデジタル署名の生成および検証に使用される鍵ペアは、他の目的に使用してはなりません。鍵の使用に関する詳細については、SP 800-57、パート1 12 を参照してください。 本規格に従ってデジタル署名の生成または検証機能を有効にするには、いくつかの手順が必要です。デジタル署名を生成するすべての当事者は、セクション3.1で説明されている初期設定プロセスを実行する必要があります。デジタル署名の生成は、セクション3.2で説明されているように実行する必要があります。デジタル署名の検証と検証は、セクション3.3で説明されているように実行する必要があります。
3.1 初期設定
図2は、署名者となる主体がデジタル署名を生成する前に実行される手順を示しています。ECDSAおよびEdDSAアルゴリズム（HashEdDSAを含む）の場合、署名者はまず、適切なドメインパラメータを取得する必要があります。これは、ドメインパラメータを自ら生成するか、他の主体が生成したドメインパラメータを取得することによって行います。ドメインパラメータを取得した後、署名者はそれらのドメインパラメータの有効性の保証を取得する必要があります。この保証を取得するための承認済みの方法は、SP 800-89 8（SP 800-186の付録D.1も参照）に記載されています。RSAアルゴリズムはドメインパラメータを使用しないことに注意してください。 各署名者は、適切なデジタル署名アルゴリズムに指定された方法で生成されたデジタル署名鍵ペアを、自ら鍵ペアを生成するか、信頼できる当事者から鍵ペアを取得することによって取得する必要があります。署名者は鍵ペアの使用を承認されており、その鍵ペアの所有者です。信頼できる当事者が鍵ペアを生成する場合、たとえ信頼できる当事者が秘密鍵を知っているとしても、その当事者が所有者になりすまさないことが信頼されている必要があることに注意してください。
鍵ペアを取得した後、署名予定者（鍵ペアの所有者）は、(1) 公開鍵の有効性の保証、および (2) 関連する秘密鍵を実際に所有していることの保証を取得する必要があります。これらの保証を取得するための承認された方法は、SP 800-89 に規定されています。
デジタル署名検証者は、署名者の身元の保証を求めます。デジタル署名が生成および検証される環境に応じて、鍵ペアの所有者（すなわち、署名予定者）は、公開鍵を登録し、相互に信頼関係にある当事者に身元の証明を行うことができます。例えば、認証局（CA）は、所有者の身元の証明を提供された後、所有者の公開鍵と身元を含む資格情報に署名して証明書を作成することができます。資格情報を認証し、証明書を配布するシステムは、本規格の範囲外です。システムの利用者および／または代理として行動する信頼された代理人が、それらの方法がセキュリティ要件を満たすと判断する限り、他の身元証明手段（例えば、身元証明情報と公開鍵を検証対象者に直接提供するなど）を採用してもよい。
3.2 デジタル署名の生成
RSA、ECDSA、およびHashEdDSAの場合、デジタル署名を生成する前に、適切な承認済みハッシュ関数を用いて、署名対象となる情報からメッセージダイジェストを生成する必要がある。
使用するデジタル署名アルゴリズムに応じて、追加情報を取得しなければならない。例えば、ECDSAの場合はメッセージごとにランダムな秘密番号を取得しなければならないが、EdDSAおよびRSAでは必要ありません。
図3：デジタル署名の生成
選択されたデジタル署名アルゴリズム、署名秘密鍵、メッセージまたはメッセージダイジェスト、およびデジタル署名プロセスに必要なその他の情報を用いて、本規格に従ってデジタル署名が生成されるものとする。
署名者は、署名検証プロセスと関連する公開鍵を用いて、オプションでデジタル署名を検証することができる（セクション3.3参照）。このオプションの検証は、そうでなければ検出されない署名生成計算エラーを検出するための最終チェックとして機能する。この検証は、高価値メッセージに署名する場合、複数のユーザーが署名を検証することが予想される場合、または検証者がかなり後の時点で署名を検証する予定である場合に、賢明な選択となる可能性がある。
図3は、署名者（すなわち、デジタル署名を生成する主体）が実行する手順を示している。
3.3 デジタル署名の検証と妥当性確認
デジタル署名を検証するために、検証者は（通常）主張署名者の公開鍵を取得しなければならない。デジタル署名の生成にECDSAまたはEdDSA（HashEdDSAを含む）が使用されている場合、検証者はドメインパラメータも取得しなければならない。公開鍵とドメインパラメータは、例えば、信頼できる機関（例えばCA）が作成した証明書から取得することも、主張署名者から直接取得することもできる。RSA、ECDSA、およびHashEdDSAの場合、署名の検証対象となるデータ（つまり、受信したデジタル署名ではないデータ）に対して、デジタル署名生成プロセスで使用されたものと同じハッシュ関数を用いてメッセージダイジェストを生成する必要がある。受信したデジタル署名は、適切なデジタル署名アルゴリズム、ドメインパラメータ（該当する場合）、公開鍵、およびメッセージダイジェストまたは新たに計算されたメッセージダイジェストを用いて、本標準に従って検証される。検証プロセスが失敗した場合、データが正しいかどうかは推論できず、指定された公開鍵と指定された署名形式を用いても、そのデータに対してデジタル署名を検証できないということのみが分かります。
検証者は、検証されたデジタル署名を有効と受け入れる前に、(1) 署名者の主張する身元の保証、(2) ドメインパラメータ（ECDSAおよびEdDSA、HashEdDSAを含む）の有効性の保証、(3) 公開鍵の有効性の保証、(4) 主張する署名者が、署名生成時にデジタル署名の生成に使用された秘密鍵を実際に所有していたことの保証を得なければなりません。検証者がこれらの保証を得るための方法は、SP 800-89に規定されています。ドメインパラメータの有効性の保証は、初期設定時に得られている場合もあることに注意してください（セクション3.1を参照）。
図4は、検証者（署名されたデータおよび関連するデジタル署名の意図された受信者など）によって実行されるデジタル署名の検証および検証プロセスを示しています。図は検証および検証プロセスが成功した場合（つまり、エラーが検出されなかった場合）を示していることに注意してください。検証および保証プロセスが成功した場合、デジタル署名は有効とみなされます。ただし、検証または保証プロセスが失敗した場合、デジタル署名は無効とみなされます。無効なデジタル署名に対して取るべき措置については、組織のポリシーに従って規定する必要があります。このようなポリシーは、本規格の範囲外です。デジタル署名されたメッセージの適時性を判断するためのガイダンスは、SP 800-102「デジタル署名の適時性に関する推奨事項」13に記載されています。 図4：デジタル署名の検証と検証$ ^6
$ ^6 EdDSAでは、メッセージ/データは署名生成および検証プロセスに入力される前にメッセージダイジェストにハッシュ化されません。
4 デジタル署名アルゴリズム (DSA)
本規格の以前のバージョンではDSAが規定されていました。本規格では、デジタル署名生成にDSAを使用することは認められていません。ただし、本規格の実装日より前に生成された署名の検証にはDSAを使用できます。DSAの仕様については、FIPS 186-4 7 を参照してください。 5. RSAデジタル署名アルゴリズム
デジタル署名の生成と検証におけるRSAアルゴリズムの使用は、IETF RFC 8017「公開鍵暗号標準 (PKCS) #1: RSA暗号化仕様 バージョン2.2」2で規定されています。この規格では、以下に列挙する追加の制約が課されています（セクション5.4を参照）。 5.1 RSA鍵ペアの生成
RSAデジタル署名鍵ペアは、デジタル署名の計算に使用されるRSA秘密鍵と、デジタル署名の検証に使用されるRSA公開鍵で構成されます。 RSAデジタル署名鍵ペアは、他の目的（鍵確立など）には使用してはならない。
RSA公開鍵は、2つの正の素数pとq（すなわちn = pq）の積である法nと、公開鍵指数eから構成される。したがって、RSA公開鍵は値のペア（n, e）であり、デジタル署名の検証に用いられる。RSA鍵ペアのサイズは、一般的に法nのビット長（nlen）とみなされる。
対応するRSA秘密鍵は、同じ法nと、nおよび公開鍵指数eに依存する秘密鍵指数dから構成される。したがって、RSA秘密鍵は値のペア（n, d）であり、デジタル署名の生成に用いられる。なお、(n, d)を表す代替方法として、中国剰余定理（CRT）を用いることも可能である（SP 800-56B 14 のセクション6.2および6.3を参照）。 デジタル署名プロセスのセキュリティを確保するため、2つの整数pとq、および秘密鍵指数dは秘密に保持されなければならない。これらの値の保護に関するガイダンスは、SP 800-57、パート1に記載されている。法nと公開鍵指数eは、誰にでも知られる可能性がある。
本規格では、ビット長が2048ビット以上の偶数である法の使用を規定している。さらに、本規格では、pとqは同じビット長、すなわちnのビット長の半分であることも規定している。法のビット長に関連するRSA方式の最大セキュリティ強度は、NIST SP 800-57、パート1 12 に規定されている。 鍵ペアおよびデジタル署名の生成時には、承認されたハッシュ関数を使用しなければならない。
RSA キー ペアの生成中に使用される場合 (この標準で指定されているとおり)、ハッシュ関数出力ブロックのビット長は、係数 n のビット長に関連付けられたセキュリティ強度を満たすか、それを超える必要があります (SP 800-57、パート 1 を参照)。
RSA デジタル署名プロセスに関連するセキュリティ強度は、係数のビット長に関連するセキュリティ強度と、使用されるハッシュ関数のセキュリティ強度の最小値以下となります (SP 800-57、パート 1 の表 3 を参照)。デジタル署名プロセス中に使用される特定の RSA 係数長および承認済みハッシュ関数に関連する (最大の) セキュリティ強度は、SP 800-57、パート 1 に規定されています。デジタル署名に使用されるハッシュ関数のセキュリティ強度と、係数 n のビット長に関連するセキュリティ強度は、どちらもデジタル署名プロセスに必要なセキュリティ強度を満たすか、それを超えている必要があります。
使用されるハッシュ関数のセキュリティ強度は、係数のセキュリティ強度以上である必要があります。そうでない場合、デジタル署名プロセスのセキュリティ強度は、ハッシュ関数によって提供されるレベルを超えないレベルに低下します。
CA は、長さ nlen が加入者が使用するすべての係数のビット長以上である係数を使用する必要があります。例えば、加入者が nlen = 2048 を使用している場合、CA は nlen ≥ 2048 を使用する必要があります。SP 800-57 のパート 1 および 3 12, 15 では、同等のセキュリティ強度に関するガイダンスについてさらに詳しく説明しています。 RSA 鍵ペアの生成基準は、付録 A.1.1 に記載されています。
RSA パラメータ（素数 p と q、およびオプションで公開鍵指数 e）をランダムに生成する場合、承認された乱数ビット生成器を使用して生成する必要があります。乱数ビット生成器によって生成された（疑似）乱数ビットは、RSA パラメータを生成するためのシードとして使用する必要があります。素数生成シードは秘密に保持するか、法 n の計算時に破棄する必要があります。素数生成シードを保持する場合（例えば、RSA 法 n を再生成するため、または生成された素因数 p と q がこの標準に準拠して生成されたことの証拠として）、シードは秘密に保持され、保護されなければなりません。この保護の強度は、関連する秘密鍵に必要な保護と（少なくとも）同等でなければなりません。
5.2 RSA鍵ペア管理
鍵ペアの保護に関するガイダンスは、SP 800-57 パート1に記載されています。デジタル署名の安全な使用は、エンティティのデジタル署名鍵ペアの管理によって以下のように決定されます。
1. 秘密鍵は、本規格で規定されているように、署名生成にのみ使用され、秘密に保持されなければなりません。公開鍵は、本規格で規定されているように、署名検証にのみ使用され、公開されても構いません。
2. 署名者は、デジタル署名を生成するために秘密鍵を使用する前、または同時に、秘密鍵を所有していることを保証されなければなりません（セクション3.1参照）。
3. 秘密鍵は、不正なアクセス、開示、および改ざんから保護されなければなりません。
4. 公開鍵は、不正な改ざん（置換を含む）から保護されなければなりません。例えば、認証局（CA）によって署名された公開鍵証明書は、このような保護を提供することができます。
5. 検証者は、公開鍵と鍵ペアの所有者との間の結びつきを保証されなければなりません（セクション3参照）。
6. 検証者は、信頼できる方法で公開鍵を取得しなければならない（例えば、エンティティが信頼する認証局によって署名された証明書から、または、当該エンティティが検証者によって信頼され、検証対象となる署名情報源として認証できることを条件として、意図された署名者または主張された署名者から直接取得する）。
7. 検証者は、主張された署名者が鍵ペアの所有者であり、署名生成時に正しい秘密鍵（すなわち、デジタル署名の検証に使用された公開鍵に関連付けられた秘密鍵）を所有者が所有していたことを保証されなければならない（セクション3.3参照）。
8. 署名者と検証者は、公開鍵の有効性について保証されなければならない（セクション3.1および3.3参照）。
5.3 保証
意図された署名者は、セクション3.1に規定される保証を得なければならない。検証者は、デジタル署名を有効と認める前に、セクション3.3に規定される保証を得なければならない。
付録A：鍵ペア生成
離散対数暗号（DLC）は、有限体暗号（FFC）と楕円曲線暗号（ECC）に分けられます。両者の違いは、使用される数学的手法の種類です。DSAはFFCの一例であり、ECDSAはECCの一例です。DLCの他の例としては、Diffie-Hellman鍵共有アルゴリズムとMQV鍵共有アルゴリズムがあり、これらはFFCとECCの両方の形式を備えています。
整数因数分解暗号（IFC）の最も一般的な例はRSAです。
この付録では、ECC鍵ペア、秘密番号、およびIFC鍵ペアの生成方法を規定します。すべての生成方法では、承認され、適切にインスタンス化された決定論的乱数ビット生成器（DRBG）を使用する必要があります。DRBGのセキュリティ強度は、生成する鍵ペアおよび秘密番号に関連付けられたセキュリティ強度と同等以上である必要があります。セキュリティ強度と鍵サイズに関するガイダンスについては、SP 800-57、パート1を参照してください。
この付録は、ビット文字列と整数間の必要な変換については規定していません。この付録のプロセスで必要な場合、変換は付録B.2に規定されているとおりに実行されなければなりません。